It looks like aggregate_string now pretty prints the collected batches and returns a String, and that is what b.iter(...) is measuring for each string benchmark.

This means the non TopK string benchmarks now include batch formatting and heap allocation overhead, which the numeric benchmarks do not include. So the comparison is no longer isolating query execution.

Would it make sense to keep a Result<()> fast path for the timed benchmark, and move the pretty_format_batches work into a one time validation helper that runs before benchmark registration?

I've changed it such that it is done in the caller path and function returns vector

Small readability thought here. Could the Utf8 vs Utf8View parity check live in a helper?

Right now criterion_benchmark is doing both benchmark registration and cross layout validation. Pulling the verification loop into something like assert_string_results_match(...) would make the benchmark matrix easier to scan.

I've extracted two helpers instead of this

The &[(bool, bool, bool)] tuple list is a bit hard to read and reason about when scanning or extending cases.

Maybe a small case struct or a helper similar to numeric_cases would help make the intent clearer. Something that names asc, use_topk, and use_view explicitly would also reduce the chance of mixing up tuple positions later.

I've made this and numeric one both structs